Providing token-based access to application features

ABSTRACT

Systems and methods are provided for implementing token-based access to application features of an application executable by a computing device. In some embodiments, a number of initial electronic credits, or tokens, may be assigned to a user of an application, where a token enables the user to access one or more features of the application. The number of tokens to be assigned to the user may be determined based at least in part on data regarding users that were previously assigned tokens of varying amounts. When a user selection is received corresponding to a request to access certain features of the application, one or more tokens may automatically be subtracted from the number of tokens available to the user. In some embodiments, additional tokens may be purchased or otherwise obtained by the user.

BACKGROUND

Computer application developers and/or distributors typically offertheir software applications to consumers for a fee. For example, asoftware distributor or software developer may allow a user to downloada computer game or other application to the user's computing device bypurchasing the game for a predetermined fee from an online marketplace.As an alternative, some software developers offer their applications tousers as a free download. In some instances, a free version of anapplication may include limited features relative to a pay version ofthe same application, and/or the free version of the application mayinclude advertisements that are presented to the user during use of theapplication.

BRIEF DESCRIPTION OF THE DRAWINGS

Specific embodiments of a system and associated processes for providingtoken-based access to application features will now be described withreference to the accompanying drawings, wherein:

FIG. 1 is a block diagram depicting an illustrative operatingenvironment in which a computing device may receive an application froman application distribution server, and in which the computing devicemay receive information regarding tokens to be used in the applicationfrom a token management server.

FIG. 2 depicts a general architecture of a computing device foroperating a token-based application.

FIG. 3 is an illustrative user interface generated for display by acomputing device during user interaction with a game, where the userinterface includes an option that may be selected by the user in orderto use an electronic token to access game functionality.

FIG. 4 is a flow diagram of an illustrative method implemented by a usercomputing device or a token management server for controlling access togame play.

FIG. 5 is a flow diagram of an illustrative method implemented by atoken management server for determining the number of free tokens toassign to a user.

FIG. 6 is an illustrative user interface generated by a computing deviceduring game play, where the user interface includes score informationand token balance information.

FIG. 7 is an illustrative user interface generated by a computing devicethat provides options to a user for obtaining additional tokens.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Aspects of the present disclosure relate to controlling access tofeatures of software, such as an application operable on a computingdevice, through the use of electronic credits or tokens that arepurchased by, given to, and/or otherwise obtained by a user of thesoftware. According to certain embodiments, a software application maybe offered for installation onto a user's computing device for free, andthe user may initially receive a given number of electronic credits ortokens for use in the application. Subsequently, each time that the useraccesses certain features within the application, the number of tokensavailable to the user may be decreased. For example, according to someembodiments in which the application is an electronic game playable on amobile computing device, each time that the user selects to begin a newinstance of game play, a certain number of tokens may be debited fromthe user's balance of tokens. If the user's available token balance isless than the number of tokens required to access the desired softwarefeature, the user may be prevented from accessing the feature until theuser obtains additional tokens according to one or more optionsdescribed further below.

In some embodiments, a token module as disclosed herein may determine anumber of initial electronic credits, or tokens, to be assigned to auser of an application, where a token enables the user to access one ormore features of the application. The number of tokens to be assigned tothe user may be determined based at least in part on data regardingusers that were previously assigned tokens of varying amounts. The tokenmodule may then store an electronic record associating the determinednumber of tokens with the user. The token module may later receive auser selection corresponding to a request to access a certain feature ofthe application, and in response to the selection, automatically modifythe electronic record to subtract one or more tokens from the number oftokens available to the user. The application may then provide the userwith access to the desired feature, at least temporarily.

As used herein, an “application” may be, for example, software that maybe executed by a computing device. While a game that may be executed ona computing device is often used below as an example of an application,it will be appreciated that aspects of the present disclosure may beimplemented in, or applicable to, various other types of software. Insome embodiments, applications may include stand-alone software packagesthat are executable within a particular operating system. In otherembodiments, applications may include cross-platform and/orbrowser-based software modules.

As used herein, a “token” may refer to a unit of electronic credit. Insome embodiments, the electronic credit may be used or spent by a userwithin one or more applications in order to access certainfunctionality, and/or may be used by an individual in other environmentsunassociated with an application, such as in exchange for real-worldgoods. In some embodiments, a token may correspond to a hard currencyvalue in a general monetary system (for example, a token may correspondto a U.S. penny, or have a one cent value associated with it). As willbe appreciated, the “value” of a token may simply convey the generalcost to purchase a token, and does not necessarily require that a userbe able to convert an available token into the token's U.S. currencyvalue. In other embodiments, a token may correspond to a “soft” valuewithin a given system that is unattached to any specific governmentalcurrency system. For example, an operator of a token management serverand/or a developer of a given application that utilizes tokens maydetermine the effective worth of a token, which may be defined in termsof what a token enables the user to do (e.g., how many tokens a usermust spend in order to access a given application feature) rather thanin terms of any cost associated with obtaining a certain number oftokens.

A token module is described herein as, in certain embodiments, groupingor segmenting users into various cohorts. As used herein, a “cohort”generally refers to a group of users with one or more commoncharacteristics or attributes, where the specific type ofcharacteristic(s) or attribute(s) upon which users are grouped may varyin different embodiments. For example, attributes may includedemographic information such as age, gender, geographic location,employment status, etc. Attributes of users may additionally oralternatively include information regarding past purchase behavior,types of electronic devices used (such as the manufacturer of a user'smobile computing device), operating systems used, extent and type ofsocial network usage, extent of application and/or game usage, number oftoken purchases, number of offer completions, etc.

FIG. 1 depicts an illustrative operating environment 100 in which acomputing device 102 may receive an application from an applicationdistribution server 104, and in which the computing device 102 mayreceive information regarding tokens to be made available to a user ofthe application from a token management server 106. The depictedenvironment 100 includes a computing device 102, an applicationdistribution server 104, and a token management server 106communicatively connected by a network 108, such as the Internet. Thoseskilled in the art will recognize that the computing device 102, tokenmanagement server 106 and/or application distribution server 104 maycollectively be any of a number of computing devices that are capable ofcommunicating over a network including, but not limited to, a laptop,personal computer, tablet computer, electronic book reader, personaldigital assistant (PDA), hybrid PDA/mobile phone, mobile phone, smartphone, digital music player, and the like. In some embodiments, one ofthe computing device 102 and the token management server 106 mayimplement aspects of the present disclosure without cooperating withanother computing device. Similarly, the application distribution server104 may not be present in the operating environment of certainembodiments.

In the illustrated embodiment, the application distribution server 104may provide access to a number of software applications, which may beretrieved by the application distribution server from one or more datastores, such as application data store 114. A user of computing device102 may browse the available applications and request that theapplication distribution server 104 send a given application to thecomputing device 102 in order for the application to be installed on thecomputing device. Once an application has been installed on computingdevice 102, the computing device 102 may request an available tokencount associated with the user from token management server 106, and maygenerally send and receive token information to and from tokenmanagement server 106 during operation of the application, as will bediscussed further below. In other embodiments, the computing device 102may determine a number of tokens to be made available to a given userand/or manage user tokens without communicating with token managementserver 106.

In the environment shown in FIG. 1, the computing device 102 maycommunicate with the application distribution server 104 and/or tokenmanagement server 106 via a communication network 108, such as theInternet or other communications link. Communications between thecomputing device 102 and the application distribution server 104 and/ortoken management server 106 may be secure, such as by encrypting orencoding the data exchanged. In some embodiments, the applicationdistribution server 104 and/or token management server 106 may includecomputer hardware and software components similar to those describedbelow with respect to the computing device 102.

As illustrated in FIG. 1, the application distribution server 104includes or communicates with an application data store 114. Theapplication data store 114 may include data associated with a number ofsoftware applications that may obtained by a user of a computing device,such as computing device 102, from the application distribution serverfor installation onto the user's computing device. For example, theapplication distribution server 104 may provide a retail environment inwhich users may purchase applications and/or may provide an interfacefrom which at least some applications are freely provided to users.Those skilled in the art will appreciate that the application data store114 may be local to the application distribution server 104, may beremote to the application distribution server 104, and/or may be anetwork-based service itself.

As further illustrated, the token management server 106 includes orcommunicates with a token data store 112. The token data store 112 mayinclude token data associated with a number of users, including tokenbalance information for each user. In some embodiments, the token datastore 112 may additionally include user data, such as demographic dataor personal information, and/or behavioral information regarding the useof tokens, purchasing activity, and/or information regarding applicationusage by a user. Those skilled in the art will appreciate that the tokendata store 112 may be local to the token management server 106, may beremote to the token management server 106, and/or may be a network-basedservice itself. In other embodiments, the token data store 112 may belocal to the computing device 102 or the application distribution server104.

Those skilled in the art will appreciate that the network 108 may be anywired network, wireless network or combination thereof. In addition, thenetwork 108 may be a personal area network, local area network, widearea network, cable network, satellite network, cellular telephonenetwork, etc., or combination thereof. Protocols and components forcommunicating via the Internet or any of the other aforementioned typesof communication networks are well known to those skilled in the art ofcomputer communications and, thus, will not be described in more detailherein.

In some embodiments, a token module that implements aspects of thepresent disclosure may be distributed to software developers in orderfor a number of different software applications to provide token-basedaccess to application features of the given applications. For example,an operator of the token management server 106 may provide anapplication programming interface (“API”) or a software development kit(“SDK”) that allows developers of applications (such as applicationsaccessible via the application distribution server 104) to integratetoken functionality within their applications.

FIG. 2 depicts a general architecture of a computing device 102 foroperating an application that requires tokens, as described herein, toaccess certain features. The computing device 102 may have one or moreprocessors 202 in communication with a network interface 204, a displayinterface 206, a computer readable medium drive 208, and an input/outputdevice interface 210, all of which communicate with one another by wayof a communication bus. The network interface 204 may provideconnectivity to one or more networks or computing systems. Theprocessor(s) 202 may thus receive information and instructions fromother computing systems or services via a network. The processor(s) 202may also communicate to and from memory 220 and further provide outputinformation or receive input information via the display interface 206and/or the input/output device interface 210. The input/output deviceinterface 210 may accept input from one or more input devices 224,including, but not limited to, keyboards, mice, trackballs, trackpads,joysticks, input tablets, trackpoints, touch screens, remote controls,game controllers, velocity sensors, voltage or current sensors, motiondetectors, or any other input device capable of obtaining a position ormagnitude value from a user. The input/output interface 210 may alsoprovide output via one or more output devices 222, including, but notlimited to, one or more speakers or any of a variety of digital oranalog audio capable output ports. The display interface 206 may beassociated with any number of visual or tactile interfaces incorporatingany of a number of active or passive display technologies, such aselectronic-ink, LCD, LED or OLED, CRT, projection, etc.

The memory 220 contains computer program instructions that theprocessor(s) 202 execute in order to implement one or more embodimentsof the present disclosure. The memory 220 generally includes RAM, ROMand/or other persistent or non-transitory computer-readable media. Thememory 220 may store an operating system 214 that provides computerprogram instructions for use by the processor(s) 202 in the generaladministration and operation of the computing device 102. The memory 220may further include other information for implementing aspects of thepresent disclosure. For example, in one embodiment, the memory 220includes a user interface module 212 that facilitates generation of userinterfaces (such as by providing instructions therefor) for display. Forexample, a user interface may be displayed via a navigation interfacesuch as a web browser installed on the computing device, or via anapplication installed on the computing device, such as an electronicgame. In addition, memory 220 may include or communicate with anauxiliary data store 240. Data stored in the data store 240 may includevarious application data and/or token data similar to that discussedabove with respect to token data store 112.

In addition to the user interface module 212, the memory 220 may includea token module 216 that may be executed by the processor(s) 202. In oneembodiment, the token module 216 may be used to implement variousaspects of the present disclosure, such as determining or requesting thenumber of tokens to associate with a given user, controlling access toapplication features, managing tokens, etc., as described further below.In certain embodiments of the present disclosure, the applicationdistribution server 104 and/or token management server 106 may includeseveral components that operate similarly to the components illustratedas part of the computing device 102, including a user interface module,processor, computer readable medium drive, etc. In some embodiments, thetoken management server 106 may include a module similar to token module216, and aspects of the present disclosure described herein asimplemented by the token module 216 may be implemented by the tokenmanagement server 106 in communication with the computing device 102.

FIG. 3 is an illustrative user interface 300 generated for display by acomputing device, such as computing device 102, during user interactionwith a game entitled “Car Racing Game.” User interface 300 may bedisplayed, for example, when an application (in this case, a game) thatimplements at least some aspects of a token module, as described herein,is executed by the computing device 102. In the illustrated embodiment,user interface 300 may be presented for display by the computing device102 the first time that the user selects to launch or open the “CarRacing Game” application after the application has been installed on theuser's computing device. In such an embodiment, the token balance 302(indicated as twenty-five available tokens) may include a number of freetokens that have been determined by the token module 216 of computingdevice and/or by the token management server 106 in communication withthe computing device, as described further below. For example, prior todisplay of user interface 300, the token module may have requested theuser's token balance from token management server 106, and may havereceived from the token management server an indication of a balance oftwenty-five tokens associated with the user based on a user identifier,device identifier, or other identifier associated with the user'saccount with the token management server 106.

According to some embodiments, a user interface similar to userinterface 300 may be presented for display after each instance of gameplay (which may correspond to a turn, a life, a time-limited instance,or other discrete amount of game play), with the token balance 302indicating a balance of one less token after each instance of game play.Accordingly, the token balance displayed at a given time may includestokens that were assigned to the user for free upon installation of thegame, tokens that were assigned to the user as a result of offerscompleted by the user, and/or tokens that were purchased by the user orfor the user by another individual. In some embodiments, the tokenbalance 302 may include tokens that were obtained by the user outside ofthe “Car Racing Game” application, such as tokens that were originallyobtained during user interaction with a different application.

As illustrated, user interface 300 includes an option 304 that may beselected by the user to use an electronic token to access gamefunctionality. In the illustrated embodiment, the game functionalitythat the user may request to access by selection of option 304 is asingle instance of game play of the “Car Racing Game” application. Inthe illustrated embodiment, the user is not provided with any option toinitiate an instance of game play other than option 304, which requiresuse of a token. Accordingly, in order for the user to access an instanceof game play (which may be considered “playing” the game), the usermust, in some embodiments, agree to allow the token module 216 tosubtract an available token from the user's token balance 302 byselecting option 304. As a result of the user's selection of option 304,the computing device may initiate an instance of game play, such as bypresenting for display a user interface similar to FIG. 6, discussedbelow, and subtract a token from the user's token balance 302 (whichwould result in a balance of twenty-four tokens in the illustratedexample).

Illustrative user interface 300 additionally includes an option 306,which the user may select if the user desires to obtain additionaltokens to be added to the user's token balance 302. Selection of option306 may result, for example, in the computing device 102 presenting fordisplay a user interface with selectable options similar to thoseillustrated in user interface 700, discussed below in reference to FIG.7. For example, the computing device may present the user with variousoffers that may be completed by the user in order for the user toreceive additional tokens, and/or may present the user with options topurchase additional tokens. If the user does not wish to use a token toaccess game functionality, the user may select quit option 308 in orderto request that the computing device end execution of the “Car RacingGame” application.

FIG. 4 is a flow diagram of an illustrative method 400 implemented byuser computing device 102 and/or token management server 106 forcontrolling access to game play. While illustrative method 400 isdescribed below in terms of controlling access to game play within agame, illustrative method 400 may be implemented in association withapplications of various types other than games in order to controlaccess to one or more application features. While illustrative method400 will be described below as implemented by the computing device 102based in part on data received from token management server 106, it willbe appreciated that, in other embodiments, illustrative method 400 maybe implemented in whole or in part by the token management server 106.

Illustrative method 400 begins at block 404, where the computing device102 determines a number of free tokens to be assigned to the user basedon the user and/or the game. In some embodiments, the number of freetokens to assign to the user within a given game or other applicationmay only be determined once for the given user, such as at the time theapplication is first installed by the user onto computing device 102, orat the time when the application is first opened by the user andexecuted by the computing device 102. In some embodiments, the number offree tokens to assign to the user may be based in part on cohortanalysis regarding token purchase data and/or token usage dataassociated with other users that share certain user attributes with thegiven user. Determining the number of free tokens to assign to the useris discussed in more detail below with reference to illustrative method500 of FIG. 5.

The “free” tokens to be assigned to the user may be tokens that the useris allotted for no monetary cost as a result of downloading theapplication from application distribution server 104, installing theapplication onto computing device 102, and/or selecting to open theapplication for execution by computing device 102. Tokens may, in someembodiments, generally be portable between different applications, suchthat a token in one application may be considered a cross-applicationtoken that may be made available for use by the same user in a secondapplication. In some such embodiments, a “free” token may have limiteduse relative to tokens obtained in other manners, such as only beingusable within the application with which the tokens are firstassociated, or only being usable within applications associated with asingle developer or distributor.

Once the computing device 102 has determined the number of free tokensto assign to the user, the computing device 102 associates thedetermined number of free tokens with the user at block 406. Associatingthe determined number of free tokens with the user may includeretrieving a previous token balance associated with the user from tokendata stored in a data store, adding the determined number of free tokensto the previous token balance, and associating the new token balancewith the user in the data store. In embodiments in which free tokenshave limited utility relative to tokens that are purchased or obtainedthrough offer completions, associating the determined number of freetokens with the user may include storing a new free token balanceassociated with the user and the given application, which may be storedas a separate balance from one or more other token balances associatedwith the user (such as the user's purchased token balance and/or theuser's free token balance associated with another application).

In some embodiments, token management server 106 may maintain tokenbalance information associated with the user and token balanceinformation associated with a number of other users in token data store112, and may send the token balance information to computing device 102in order for the user to access his tokens in the given application. Inother embodiments, the computing device 102 may maintain token balanceinformation in a local data store, such as data store 240. In otherembodiments, the token management server 106 and computing device 102may each maintain a token balance associated with the user in separatedata stores, and may communicate with each other periodically or inresponse to certain triggering events in order to synchronize the tokenbalance information between the different data stores. For example, thetoken management server 106 may update token balance information intoken data store 112 in response to an indication from computing device102 that the user has used five tokens in an application executed bycomputing device 102. Similarly, the computing device 102 may updatetoken balance information in data store 240 in response to an indicationfrom token management server 106 that the user has used five tokens inanother application and/or using a different computing device.

At block 408, the computing device 102 receives a user selectioncorresponding to a game play request. For example, the selection may bereceived as a result of the user selecting an option displayed in a userinterface generated by the application, such as the “play” option 304discussed above with reference to illustrative user interface 300 ofFIG. 3. The selection received at block 408 may generally correspond toa request by the user to access a feature of the game or otherapplication that requires use of one or more tokens. Once the computingdevice 102 receives the user selection at block 408, such as a selectionindicating a request to begin a new instance of game play, the computingdevice retrieves the available token count associated with the user atblock 410. In some embodiments, the available token count associatedwith the user may be retrieved directly by the computing device 102,such as from data store 240. In other embodiments, the computing device102 may send a request to the token management server 106. The tokenmanagement server 106 may then retrieve the user's available token countfrom token data store 112 based on a user identifier associated with theuser, and may send the retrieved token count to the computing device102.

Next, at block 412, the computing device 102 determines whether the userhas sufficient tokens available to access the application featurerequested at block 408. For example, if the user has requested to begina new instance of game play, and a new instance of game play in thegiven application requires use of two tokens, the computing device maydetermine at block 412 whether the user's available token count isgreater than or equal to two tokens. If the computing device determinesthat the user does not have sufficient tokens available, the methodproceeds to block 414, where access to the requested game play featureis blocked until the user obtains additional tokens, as described inmore detail below. The illustrative method 400 then ends at block 420.

If the computing device instead determines that the user has sufficienttokens available at block 412, the method proceeds to block 416, wherethe computing device subtracts the required tokens from the user's tokencount and provides access to the game play instance or other applicationfeature requested by the user. For example, if the user's selectioncorresponded to a request to initiate an instance of game play at a costof two tokens, the computing device may initiate an instance of gameplay (such as by presenting for display a user interface similar to FIG.6, discussed below) and subtract two tokens from the user's tokenbalance. Once the user's game play instance has ended (which may bedefined in different ways depending on the game, but may include theuser exceeding a game play time limit, the user losing a certain numberof “lives” within the game, etc.) at block 418, the illustrative method400 may return to block 408, where the user may select to begin a newinstance of game play. The illustrative method 400 may end as a resultof the user selecting to exit the game or end execution of theapplication by computing device 102 (not illustrated).

FIG. 5 is a flow diagram of an illustrative method 500 implemented byuser computing device 102 and/or token management server 106 fordetermining the number of free tokens to assign to a user. Whileillustrative method 500 will be described below as implemented by thecomputing device 102 based in part on data received from tokenmanagement server 106, it will be appreciated that, in otherembodiments, illustrative method 500 may be implemented in whole or inpart by the token management server 106 or by another computing systemor component. Illustrative method 500 is an example of a method that maybe implemented at block 404 of illustrative method 400, discussed above,in order to determine how many free tokens to assign to a user.

Illustrative method 500 begins at block 502, where the computing device102 retrieves information associated with the user. The retrievedinformation may include, for example, one or more attributes associatedwith the user, such as geographic location, gender, occupation, and/orother demographic or personal data. The information may be retrieved, insome embodiments, from one or more third party data stores or receivedfrom one or more third party servers. For example, an applicationimplemented by the computing device 102, such as a game, may present theuser with a user interface prompting the user to enter a user identifierthat may be used by the computing device 102 and/or token managementserver 106 to request information regarding the user from a third partyserver, such as a server operated by a social networking service withwhich the user maintains an account, the application distribution server104, a electronic commerce retailer, or other service provider. Forexample, the user may enter a username and password associated with theuser's account with the social networking service or other service, andthe computing device 102 may request information regarding the user froma server associated with the social networking service or other service.In other embodiments, the user may have previously set up an accountwith the application distribution server 104 and/or token managementserver 106, from which the computing device 102 may access userattribute information associated with the user's account. In someembodiments, the computing device 102 may retrieve personal and/ordemographic information regarding the user directly from one or moredata stores local to computing device 102, and/or may utilizegeolocation functionality of the computing device 102 to determine thecurrent geographic location of the user (which may be considered a userattribute, in certain embodiments).

At block 504, the computing device 102 identifies other users that aresimilar to the user based on the information regarding the user that wasretrieved or received by the computing device 102 at block 502. In someembodiments, identifying other users that are similar to the user mayinclude determining a cohort with which to associate the user. Asdiscussed above, a cohort may generally be a group of users with one ormore common characteristics or attributes, where specific cohorts may bedefined in various ways in different embodiments. For example, onecohort may be defined as 18-25 year old males, while another cohort maybe defined as students at U.S. universities. The computing device mayplace the user in a cohort, or otherwise identify users that are similarto the user, by comparing one or more attributes of the user withattributes of a number of other users of the token management server106. In some embodiments, information regarding user attributesassociated with other users may be retrieved from a data store, such astoken data store 112. In other embodiments, the token management server106 may provide the token module 216 with cohort definitions in orderfor the token module to determine a cohort with which to associate theuser.

After the computing device 102 has identified other users, or a cohortof users, that are similar to the user, the illustrative method 500proceeds to block 506, where the computing device analyzes token usageinformation of the similar users and/or token purchase history of thesimilar users. In order to analyze token usage and/or purchase historydata, the computing device may retrieve from one or more data stores,such as token data store 112, information regarding the number of freetokens that have previously been assigned to the similar users, thenumber of tokens that have been used by the similar users in one or moreapplications, the amount of money spent on token purchases, and/or othertoken data associated with the users. In some embodiments, analyzing thetoken data may include determining an optimal number of free tokens toassign to a user of a given cohort (or a user that is associated withcertain attributes) in order to maximize a given target metric or value.For example, according to some embodiments, the token module 216 may beconfigured to maximize a conversion rate of users, where a conversionrate may be defined as the percentage of users that eventually purchasetokens at least once after receiving a given number of free tokens.Alternatively, the token module 216 may be configured to maximize alifetime value of a user, which may be defined as the total amount ofmoney spent by a user in purchasing tokens over an extended period oftime.

At block 508, the computing device 102 determines the number of tokensto assign to the user based on the analysis of similar users implementedat block 506. In some instances, the number of tokens to be assigned tothe user may be the number of tokens determined above to be optimal forusers of the given cohort. According to some embodiments, the computingdevice 102 may randomly vary the number of free tokens to initiallyassign to each user of a given cohort in order to test the success ofdifferent token amounts until a certain confidence level is achieved inthe optimal token amount. In other embodiments, a certain subset ofusers of a given cohort may be assigned random token amounts within agiven range for testing purposes, or all users of a given cohort may beassigned random token amounts until a certain minimum sample size isachieved for the given cohort. Once the number of tokens to assign tothe given user has been determined, the illustrative method 500 ends atblock 510.

Although FIG. 5 depicts the token usage analysis as being performed fora particular user, this need not be the case. For example, in someembodiments, the usage analysis may instead be performed periodically(e.g., daily, weekly or monthly) for specific groups or segments of theuser population, and the results stored for subsequent look up. Theseresults may, for example, associate specific cohort descriptions (e.g.,certain attribute values for certain user attributes) with specificnumbers of initial tokens, and may be used to determine the number ofinitial tokens to assign to particular users.

While illustrative method 500 is described above in terms of anembodiment in which information associated with the user, such as userattributes, is considered by the computing device 102 when determiningthe number of free tokens to assign to a user, in other embodiments, thecomputing device 102 may not consider information associated with theuser when determining the number of free tokens to assign to a user. Forexample, in some embodiments, the number of free tokens to assign to theuser may be based on an analysis by the token management server 106 oftoken usage data and/or token purchase data associated with users of agiven application without regard to cohorts or similarities betweenusers. A token module in such an embodiment may generally be configuredto analyze token data in order to determine the number of free tokensthat is optimal for a given application, rather than for a given user orgroup of users. In other embodiments, the number of initial tokens toassign to a given user may be based partly or wholly on past behavior ofthe particular user. For example, a user who has previously madesubstantial token purchases and/or application purchases after runningout of his initial free tokens in other applications may be awarded moretokens than would otherwise be the case for a user with similarattributes. On the other hand, in some such embodiments, a specific userwho rarely purchase tokens may, over time, be awarded fewer tokens uponsubsequent installation of token-based applications than would otherwisebe the case for other users within the given cohort.

FIG. 6 is an illustrative user interface 600 generated by computingdevice 102 during game play of a game application executed by thecomputing device. The game may be, for example, the game entitled “CarRacing Game” previously discussed as an example application above withreference to FIG. 3. Illustrative user interface 600 may be displayedduring an instance of game play after the user has selected to use atoken to play the game, such as by selecting option 304 of userinterface 300 discussed above. Accordingly, the user's token balance604, indicated as twenty-four tokens, may be a revised balance totalingone less token than the user's previous balance of twenty-five tokens.The token balance may have been updated automatically by the tokenmodule 216 in response to the user selecting to begin a new instance ofgame play. In some embodiments, once the user's game play instance ends,such as by the user completing a given race within the user interface600 of the “Car Racing Game,” the user may be prompted to play again ata cost of one additional token.

User interface 600 includes a score 602 that reflects the user's currentscore in the instance of game play, which may be updated as the userplays the game. User interface 600 also includes a high score ranking606 that indicates where the user's personal high score for the gameranks relative to other users' high scores. In some embodiments, thehigh score ranking 606 may include scores of other users with whom theuser is connected within one or more social networks. For example, thetoken module 216 may access information identifying a user's socialconnections or friends from one or more social networking services, suchas by communicating with the a server associated with the socialnetworking service and/or through an API provided by the socialnetworking service. The user may have previously indicated to the tokenmanagement server 106 a number of the user's friends or socialconnections that the user was interested in competing with for highscore(s), which may include “Joe” and “Mark” in the illustrated highscore ranking 606. In other embodiments, the high score ranking 606 mayinclude users that are associated with accounts with the tokenmanagement server 106, whether or not such users are connected on anysocial networking service. The presence of high score ranking 606 mayserve to encourage the user to continue using tokens and/or to purchaseadditional tokens in order to have additional chances to beat a friend'shigh score in the game. Additionally, high score ranking 606 includes anoption 608 which the user may select in order to invite a social networkconnection of the user, indicated as “Alex,” to compete with the userfor high scores and/or to sign up for an account with the tokenmanagement server 106.

FIG. 7 is an illustrative user interface 700 generated by a computingdevice, such as computing device 102, or generated in whole or in partby token management server 106 to be presented for display by computingdevice 102, that provides options to a user for obtaining additionaltokens. User interface 700 may be displayed, for example, when theuser's token balance reaches zero (indicated by token balance 702), suchthat the user can no longer use an available token to begin a newinstance of game play (or access some other token-controlled applicationfunctionality). In some embodiments, a user interface similar to userinterface 700 may be displayed by the computing device 102 in responseto certain selections by the user, whether or not the user currently hastokens available.

User interface 700 includes four illustrative options 704, 706, 708 and710 for the user to select from in order to obtain additional tokens.Options 704 and 706 may be selected by the user in order for the user tobe prompted for payment information to purchase 99 tokens or 499 tokens,respectively. For example, selection of option 704 may present the userwith a user interface that enables the user to purchase 99 tokens for$0.99, or some other amount, depending on the embodiment. The user maybe offered a variety of payment options, such as payment by credit cardor by the user's account associated with the application distributionserver 104, an online payment processor, an e-commerce retailer, a phonecarrier or service provider, or other payment processor. After paymentprocessing, the token management server 106 may add 99 tokens to theaccount balance associated with the user in token data store 112.

Illustrative user interface 700 also includes option 708, which the usermay select in order to earn five free tokens as a reward for inviting afriend to set up an account with the token management server 106.Selection of option 708 may, for example, present the user with optionsto select an individual from a list of the user's social connections onone or more third-party social networking services and/or enter an emailaddress associated with the friend to be invited. Once the user hasindicated a friend to invite, the token management server 106 may addfive tokens to the user's token balance and send an invitation to theselected friend by email, text message, message within a socialnetworking service, and/or other communication.

Option 710 of user interface 700 may be selected by the user to viewother offers that the user may complete in order to receive tokenswithout monetary payment. For example, in some embodiments, the user maybe presented with options of one or more additional applications thatthe user may select to install on the computing device 102. Theadditional application may be, for example, an application that isdistributed by an application distributor that has offered to pay theoperator of token management server 106 for each user installation ofthe offered application, or for each user that both installs andactually uses the offered application. In some embodiments, the tokenmanagement server 106 may add a certain number of tokens associated withthe offer to the user's token balance once the user installs theapplication, while in other embodiments the user may be required toactually use the installed application before receiving the free tokensassociated with the offer. In some embodiments, the price that thedistributor or developer of the offered application pays to the operatorof the token management server 106 for the user's installation of theoffered application may vary depending on one or more metrics tracked bythe token management server 106, such as the number of times usersactually use the offered application after installation, the amount oftime users spend in the offered application, the number of tokens thatthe user spends in the offered application, etc.

It is to be understood that not necessarily all objects or advantagesmay be achieved in accordance with any particular embodiment describedherein. Thus, for example, those skilled in the art will recognize thatcertain embodiments may be configured to operate in a manner thatachieves or optimizes one advantage or group of advantages as taughtherein without necessarily achieving other objects or advantages as maybe taught or suggested herein.

All of the processes described herein may be embodied in, and fullyautomated via, software code modules executed by one or more generalpurpose computers or processors. The code modules may be stored in anytype of computer-readable medium or other computer storage device. Someor all the methods may alternatively be embodied in specialized computerhardware. In addition, the components referred to herein may beimplemented in hardware, software, firmware or a combination thereof.

Conditional language such as, among others, “can,” “could,” “might” or“may,” unless specifically stated otherwise, are otherwise understoodwithin the context as used in general to convey that certain embodimentsinclude, while other embodiments do not include, certain features,elements and/or steps. Thus, such conditional language is not generallyintended to imply that features, elements and/or steps are in any wayrequired for one or more embodiments or that one or more embodimentsnecessarily include logic for deciding, with or without user input orprompting, whether these features, elements and/or steps are included orare to be performed in any particular embodiment.

Conjunctive language such as the phrase “at least one of X, Y and Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to convey that an item, term, etc. may beeither X, Y or Z. Thus, such conjunctive language is not generallyintended to imply that certain embodiments require at least one of X, atleast one of Y and at least one of Z to each be present.

Any process descriptions, elements or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or elements in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown, or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved as would be understood by those skilled in the art.

It should be emphasized that many variations and modifications may bemade to the above-described embodiments, the elements of which are to beunderstood as being among other acceptable examples. All suchmodifications and variations are intended to be included herein withinthe scope of this disclosure and protected by the following claims.

What is claimed is:
 1. A system for providing electronic access to oneor more features of a computer game, the system comprising: a data storethat stores data identifying at least one user and a number of tokensavailable to the at least one user, wherein a token represents anelectronic credit that may be used to access game functionality of oneor more computer games; and a computing system in communication with thedata store and that is operative to: receive an indication that a userhas requested initial access to a computer game, wherein the computergame requires usage of a token in order to access an instance of gameplay; determine a number of initial tokens to be assigned to the userbased at least in part on information associated with the user and tokenusage data associated with a plurality of users; store a token countassociated with the user in the data store, such that the token countincludes the determined number of initial tokens; receive an indicationthat the user has selected to initiate an instance of game play withinthe computer game; and in response to receiving the indication,automatically subtract a token from the stored token count associatedwith the user.
 2. The system of claim 1, wherein the computing device isfurther operative to enable the user to electronically purchase aplurality of tokens in order to access an instance of game play.
 3. Thesystem of claim 1, wherein the computer game comprises a game playableon a mobile computing device.
 4. The system of claim 3, wherein themobile computing device is a mobile phone.
 5. The system of claim 1,wherein the indication that the user has requested initial access to acomputer game is received based at least in part on the computer gamebeing installed on a computing device associated with the user.
 6. Thesystem of claim 1, wherein the computing device is further operative topresent one or more offers to be completed by the user in order toincrease the token count associated with the user.
 7. The system ofclaim 1, wherein determining the number of initial tokens to be assignedto the user comprises analyzing token usage data associated with aplurality of users that are each associated with at least one userattribute associated with the user.
 8. The system of claim 1, whereinthe number of initial tokens to be assigned to the user is determinedprior to receiving the indication that the user has requested initialaccess to the computer game.
 9. A system for managing tokens inassociation with one or more applications, the system comprising: a datastore that stores data identifying a plurality of users and a number oftokens associated with each of the plurality of users, wherein a tokenrepresents an electronic credit that may be used to access functionalityof one or more applications that are executable by at least onecomputing device; and a computing system in communication with the datastore and that is operative to: determine one or more user attributesassociated with a user of at least one of the one or more applications;identify a cohort of users within the plurality of users with which toassociate the user, wherein the cohort is determined based at least inpart on one or more user attributes associated with the user; determinea number of tokens to be assigned to the user based at least in part ontoken data associated with users of the identified cohort; and storeinformation in the data store associating the determined number oftokens with a user identifier associated with the user, such that thetokens are made available for use by the user in one or moreapplications.
 10. The system of claim 9, wherein the token dataassociated with users of the identified cohort comprises a number oftokens previously assigned to each user of the cohort and token purchaseinformation associated with each user of the cohort.
 11. The system ofclaim 9, wherein determining the number of tokens to be assigned to theuser based at least in part on token data associated with users of theidentified cohort comprises retrieving from the data store an optimaltoken amount associated with the identified cohort.
 12. The system ofclaim 9, wherein determining the number of tokens to be assigned to theuser comprises determining a number of tokens that is likely to maximizea total dollar amount of subsequent purchases of tokens by the user. 13.The system of claim 12, wherein the number of tokens that is likely tomaximize a total dollar amount of subsequent purchases of tokens by theuser is determined based at least in part by analyzing a total dollaramount of token purchases by each of one or more users of the cohort ofusers and a number of tokens initially assigned to each of the one ormore users of the cohort.
 14. The system of claim 9, wherein determiningthe number of tokens to be assigned to the user comprises determining anumber of tokens that is likely to result in the user subsequentlypurchasing additional tokens, wherein the likelihood of the usersubsequently purchasing additional tokens is determined based on ananalysis of previous token purchase data of users of the cohort.
 15. Thesystem of claim 9, wherein the one or more applications comprise a game,wherein the functionality of the one or more applications which a tokenmay be used to access comprises initiating an instance of game play. 16.The system of claim 9, wherein the one or more user attributes comprisesat least one of age, gender and geographic location.
 17. The system ofclaim 9, wherein the one or more user attributes comprises at least oneof a number of past token purchases, a type of electronic device used,and an amount of application usage time.
 18. The system of claim 9,wherein the number of tokens to be assigned to the user is determined inresponse to receiving an indication that the user has installed on acomputing device one of the one or more applications in which the tokensare made available for use.
 19. A computer-implemented method forproviding electronic access to one or more features of an applicationexecutable by a computing device, the computer-implemented methodcomprising: as implemented by one or more computing devices configuredwith specific executable instructions: determining a number of initialelectronic credits to be assigned to a user, wherein an electroniccredit enables a user to access one or more features of the application,wherein the number of electronic credits to be assigned to the user isdetermined based at least in part on results of a token usage analysisof a plurality of users; storing an electronic record associating thedetermined number of electronic credits with the user; receiving a userselection corresponding to a request to access one of the one or morefeatures of the application; and in response to receiving the userselection, automatically modifying the electronic record to subtract oneor more electronic credits from the number of electronic creditsassociated with the user.
 20. The computer implemented method of claim19, further comprising blocking access to the one or more features ofthe application when the number of electronic credits associated withthe user is insufficient.
 21. The computer-implemented method of claim19, wherein determining the number of initial electronic credits to beassigned to the user comprises analyzing electronic credit usage data ofat least 1,000 users.
 22. The computer-implemented method of claim 19,further comprising associating additional electronic credits with theuser in response to receiving an indication that the user has completedone or more offers.
 23. The computer-implemented method of claim 22,wherein the one or more completed offers comprise the user inviting oneor more individuals to request electronic credits.
 24. Thecomputer-implemented method of claim 22, wherein the one or morecompleted offers comprise the user selecting to install a secondapplication onto a computing device of the user.
 25. Thecomputer-implemented method of claim 19, further comprising providingfunctionality within the application for the user to purchase additionalelectronic credits.
 26. The computer-implemented method of claim 19,wherein the number of electronic credits to be assigned to the user isdetermined based at least in part on previous token purchase dataassociated with the user.
 27. The computer-implemented method of claim19, wherein determining the number of initial electronic credits to beassigned to the user comprises determining a number of initialelectronic credits that is likely to result in the user subsequentlypurchasing additional electronic credits.
 28. The computer-implementedmethod of claim 27, wherein the likelihood of the user subsequentlypurchasing additional electronic credits is determined based at least inpart on electronic credit purchasing data associated with a plurality ofusers that were previously assigned electronic credits of varyingamounts.
 29. A non-transitory computer-readable medium having acomputer-executable component for managing tokens in association withone or more applications executable by one or more computing devices,the non-transitory computer-readable medium comprising: a tokenassignment component for: storing an electronic record associating anumber of tokens with a user identifier identifying a user of anapplication, wherein a token enables the user to access one or morefeatures of the application, wherein the number of tokens to associatewith the user is determined based at least in part on one or moreattributes associated with the user; and a token management componentfor: receiving an indication that the user has requested to access oneof the one or more features of the application, wherein the one of theone or more features is associated with a cost of a given number oftokens; and modifying the stored electronic record to indicate adecreased number of tokens associated with the user identifier based onthe cost associated with accessing the one or more features of theapplication.
 30. The non-transitory computer-readable medium of claim29, wherein the number of tokens to associate with the user isdetermined based at least in part on a number of tokens purchased byeach of a plurality of users with one or more attributes in common withthe user.
 31. The non-transitory computer-readable medium of claim 29,wherein the token assignment component generates for display one or moreuser interfaces that provide one or more selectable options for the userto obtain additional tokens.
 32. The non-transitory computer-readablemedium of claim 31, wherein one of the one or more selectable optionscomprises an option for the user to purchase additional tokens.
 33. Thenon-transitory computer-readable medium of claim 31, wherein one of theone or more selectable options comprises an option for the user tocomplete an offer in order to obtain tokens for no monetary cost. 34.Non-transitory computer storage that stores executable instructions thatdirect a computing system to perform a process that comprises: analyzingtoken usage of a plurality of users that fall within a user class, saiduser class defined in terms of one or more user attributes, wherein atoken represents an electronic credit that may be used to accessfunctionality of a computer application; and based on said token usage,determining a number of initial tokens to assign to at least oneadditional user falling in said user class.
 35. The non-transitorycomputer storage of claim 34, wherein the number of initial tokens toassign to the at least one additional user is determined based at leastin part on a number of tokens initially assigned to one or more of theplurality of users that fall within the user class and token purchaseinformation associated with the one or more of the plurality of usersthat fall within the user class.